Conversation
Add a new `es-toolkit/color` subpath with ANSI terminal color utilities: - 16 basic colors, bright variants, and background colors - Extended colors: ansi256, rgb, hex - Color level detection (FORCE_COLOR, NO_COLOR, TTY, COLORTERM, TERM) - stripAnsi utility - createColors factory for custom instances - Pre-configured `color` object for direct usage
Add reference docs for color, createColors, colorLevel, and stripAnsi in English, Korean, Japanese, and Chinese. Update sidebar configs.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
parseInt('abcxyz', 16) silently parses 'abc' and ignores 'xyz'.
Switch to Number('0x' + str) which returns NaN for any non-hex character.
Validate hex strings with /^[0-9a-fA-F]{3}$|^[0-9a-fA-F]{6}$/ instead
of Number('0x' + str). Only #RGB and #RRGGBB are accepted — #RGBA and
#RRGGBBAA are excluded because ANSI terminals don't support alpha.
- Rename stripAnsi to stripColor to clarify SGR-only scope - Add ./color to ENTRYPOINTS in check-dist.spec.ts - Document that colorLevel is evaluated once at import time
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1683 +/- ##
========================================
Coverage 99.97% 99.97%
========================================
Files 497 548 +51
Lines 4662 4777 +115
Branches 1348 1369 +21
========================================
+ Hits 4661 4776 +115
Misses 1 1 🚀 New features to boost your workflow:
|
| const str = toString(text); | ||
|
|
||
| if (str === '') { | ||
| return ''; | ||
| } | ||
|
|
There was a problem hiding this comment.
What about requiring strings in text and removing this logic?
| @@ -0,0 +1,93 @@ | |||
| // @vitest-environment node | |||
There was a problem hiding this comment.
There might be some edge cases here -- I think we need to make the test cases more complete.
| * const noColor = createColors(false); | ||
| * noColor.red('hello'); // 'hello' | ||
| */ | ||
| export function createColors(enabled?: boolean): Colors { |
There was a problem hiding this comment.
What about we make these into functions like this?
export function reset(str: string) {
if (detectColorLevel()) {
return str;
}
return formatWithColor(str, '\x1b[0m', '\x1b[0m');
}
There was a problem hiding this comment.
import colors from 'es-toolkit/colors';I think we also have to provide this too
There was a problem hiding this comment.
import * as colors from './colors';
export default colors;
Require callers to pass strings to color functions (no more `unknown` coercion via `String(text)`). This matches es-toolkit's stricter API philosophy and removes a tiny per-call cost. Split the monolithic `formatter.ts` into `createFormatter.ts` (the factory) and `parseHex.ts` (the hex parser) so each concern has its own file and spec.
Each color function (red, bold, hex, …) now lives in its own
file with its own spec, enabling tree-shaking when users only
need one or two utilities.
The `createColors(enabled)` factory is removed — runtime toggling
was not a real need. `FORCE_COLOR`/`NO_COLOR` environment variables
and auto-detection cover the common cases; tests force enable via
`vi.mock('./colorLevel.ts')`.
Usage:
import { red, bold, hex } from 'es-toolkit/color';
import color from 'es-toolkit/color';
red('error');
color.bold(color.red('error'));
Internally, a shared `makeColor` factory wires each utility to
`createFormatter` when color is supported, or an identity
passthrough otherwise.
Backgrounds wrapped across CRLF (`\r\n`) previously left the `\r` inside the background scope, which could render incorrectly on terminals that reset cursor position on CR. Match chalk's behavior by handling `\r?\n` as one atomic newline. Also add a spec for the `makeColor` disabled path to bring the color module to 100% branch coverage.
Rewrite the color reference in all four languages to list every
utility up front and show the new import patterns:
import { red } from 'es-toolkit/color';
import color from 'es-toolkit/color';
Remove the `createColors` page since the factory was dropped.
…trol-regex The regex literal `/\u001b\[[0-9;]*m/g` tripped ESLint's `no-control-regex` rule because the escape sequence resolved to a control character. Build the pattern through `RegExp` with `String.fromCharCode(0x1b)` so the control byte stays out of the source at lint time. Also update the JSDoc example to use the new individual imports.
The `Colors` interface was the return type of the removed `createColors` factory and has no remaining callers.
|
|
||
| // Re-open the outer style when a nested call with the same color | ||
| // inserts a close code inside the text. | ||
| if (open !== close && result.includes(close)) { |
There was a problem hiding this comment.
Why is open !== close needed here?
| * 7. Node.js hasColors() — Runtime API (Node 11.13+) for accurate detection | ||
| * 8. Default — Basic 16 colors if none of the above matched | ||
| */ | ||
| export function detectColorLevel(): ColorLevel { |
There was a problem hiding this comment.
I think we have to simplify this function.
Summary
es-toolkit/colorsubpath for terminal color utilitiesFORCE_COLOR=0handling,processReferenceError, CI pipe detectionstripAnsi,createColors,colorLevel,isColorSupportedcolorobject for direct usage (color.red('hello'))Test plan
yarn vitest run src/color/— all 55 tests passyarn lint— no errors insrc/color/tsc --noEmit— no type errorsyarn build— dist/color/ generated correctly/reference/color/color